Update Maven configuration for Central Repository publishing#116
Conversation
- Remove distributionManagement pointing to s01.oss.sonatype.org - Fix SCM URLs to HTTPS (was git:// and ssh://) - Add distribution=repo to MIT license entry - Replace release profile: remove nexus-staging-maven-plugin, add central-publishing-maven-plugin 0.9.0, upgrade maven-gpg-plugin to 3.2.7 with keyname + --pinentry-mode loopback, add source 3.3.1 and javadoc 3.11.2 plugins; retain cuda classifier jar execution
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| <plugin> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-javadoc-plugin</artifactId> | ||
| <version>3.11.2</version> |
There was a problem hiding this comment.
maven-javadoc-plugin v3.5.0 (line 136), but this release profile specifies v3.11.2. This is a significant version jump (v3.5 → v3.11) with potentially breaking changes.
Consider:
- Unify versions: Use the same version in both profiles, or explain why the release profile needs a newer version
- Check compatibility: Review the v3.11.2 release notes for any breaking changes or behavioral differences from v3.5.0
- Remove redundancy: Lines 159-167 duplicate the maven-source-plugin definition from the base build. Remove this duplication or explain why it's needed in the release profile
| <configuration> | ||
| <keyname>${gpg.keyname}</keyname> | ||
| <gpgArguments> | ||
| <arg>--pinentry-mode</arg> | ||
| <arg>loopback</arg> | ||
| </gpgArguments> |
There was a problem hiding this comment.
GPG Configuration - Documentation Needed: The --pinentry-mode loopback configuration enables non-interactive GPG signing, which is appropriate for CI/CD environments. However, this requires specific setup that should be documented:
- The GPG agent must have
allow-loopback-pinentryconfigured in~/.gnupg/gpg-agent.conf - The
${gpg.keyname}property must be set (typically via-Dgpg.keyname=<key-id>or in~/.m2/settings.xml) - The GPG passphrase needs to be available to the build environment (e.g., via environment variable or
~/.m2/settings.xml)
Recommendation: Add a comment or update documentation (CONTRIBUTING.md or README) with these requirements for maintainers setting up release builds.
| <configuration> | ||
| <publishingServerId>central</publishingServerId> | ||
| <autoPublish>true</autoPublish> | ||
| <waitUntil>published</waitUntil> | ||
| </configuration> |
There was a problem hiding this comment.
Central Publishing Maven Plugin Configuration: The migration from OSSRH to Sonatype Central Portal is correct and uses appropriate configuration:
✅ publishingServerId: central correctly replaces legacy ossrh ID
✅ autoPublish: true automates the publishing workflow
✅ waitUntil: published ensures artifacts are fully available before build completion
Note: Users will need to configure credentials in ~/.m2/settings.xml:
<server>
<id>central</id>
<username>SONATYPE_USERNAME</username>
<password>SONATYPE_PASSWORD</password>
</server>This should be documented for contributors who need to perform releases. Also ensure CI/CD credentials are properly scoped to this server ID.
Review SummaryOverall Assessment ✅The migration from OSSRH to Sonatype Central Portal is well-executed. The modern Central Publishing Maven Plugin is the correct choice, and the GPG signing configuration is appropriate for CI/CD workflows. Key FindingsIssues to Address:
Documentation Gaps:
Security & Quality Notes
Recommendations
|
Plugins (main build): - maven-compiler-plugin 3.13.0 -> 3.15.0 - maven-resources-plugin 3.3.1 -> 3.5.0 - maven-source-plugin 3.3.0 -> 3.4.0 - maven-javadoc-plugin 3.5.0 -> 3.12.0 Plugins (release profile): - maven-source-plugin 3.3.1 -> 3.4.0 - maven-javadoc-plugin 3.11.2 -> 3.12.0 - maven-gpg-plugin 3.2.7 -> 3.2.8 - central-publishing-maven-plugin 0.9.0 -> 0.10.0 - maven-jar-plugin 3.4.2 -> 3.5.0 Dependencies: - jackson-databind 2.21.2 -> 2.21.3 - org.jetbrains:annotations 24.1.0 -> 26.1.0 Skipped: Maven 4.x beta/rc plugins
Review: PR #116 - Maven Central Repository MigrationOverall Assessment ✓The migration from legacy OSSRH to Sonatype Central Publishing Maven Plugin is implemented correctly and follows modern Maven best practices. The plugin version updates are to stable releases. Key Changes Reviewed
Issues Found1. Duplicate Plugin Configuration (Medium)
2. GPG Keyname Property Documentation (Minor) Recommendations
|
| <plugin> | ||
| <groupId>org.sonatype.plugins</groupId> | ||
| <artifactId>nexus-staging-maven-plugin</artifactId> | ||
| <version>1.6.13</version> | ||
| <extensions>true</extensions> | ||
| <configuration> | ||
| <serverId>ossrh</serverId> | ||
| <nexusUrl>https://s01.oss.sonatype.org/</nexusUrl> | ||
| <autoReleaseAfterClose>true</autoReleaseAfterClose> | ||
| </configuration> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-source-plugin</artifactId> | ||
| <version>3.4.0</version> | ||
| <executions> | ||
| <execution> | ||
| <id>attach-sources</id> | ||
| <goals><goal>jar-no-fork</goal></goals> | ||
| </execution> | ||
| </executions> |
There was a problem hiding this comment.
The maven-source-plugin configuration here is identical to lines 120-131 in the main build section. Since the main build already generates source artifacts, this duplication in the release profile is unnecessary.
Suggestion: Remove this plugin block from the release profile. The main build will provide the source artifacts, and the release profile can focus solely on signing and publishing.
| <plugin> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-javadoc-plugin</artifactId> | ||
| <version>3.12.0</version> | ||
| <executions> | ||
| <execution> | ||
| <id>attach-javadocs</id> | ||
| <goals><goal>jar</goal></goals> | ||
| </execution> | ||
| </executions> | ||
| </plugin> |
There was a problem hiding this comment.
The maven-javadoc-plugin configuration here is identical to lines 133-148 in the main build section. This duplication should be removed from the release profile.
Why: The main build already runs these plugins and generates artifacts. The release profile should only add signing and publishing-specific configuration, not duplicate the main build's work.
| <configuration> | ||
| <keyname>${gpg.keyname}</keyname> | ||
| <gpgArguments> | ||
| <arg>--pinentry-mode</arg> | ||
| <arg>loopback</arg> | ||
| </gpgArguments> | ||
| </configuration> |
There was a problem hiding this comment.
📝 CI/CD Configuration Note
The ${gpg.keyname} property and --pinentry-mode loopback configuration are correct for automated signing in CI/CD environments. However, ensure that:
- The CI/CD pipeline passes
-Dgpg.keyname=<GPG_KEY_ID>when invoking the release build - The GPG passphrase is available via
GPG_PASSPHRASEenvironment variable or settings.xml - Release documentation is updated with these requirements
Example CI command: mvn clean deploy -Prelease -Dgpg.keyname=ABC123DEF
Review SummaryThis PR migrates the Maven build from OSSRH to Sonatype Central Publisher Portal with updated dependencies and a new Dependabot configuration. While the migration approach is sound, there are several points worth addressing: Issues Found1. Significant SCM Connection URL Change
2. Duplicate Plugin Configurations
3. Configuration Details
Positive Aspects✅ Dependabot configuration is well-structured for both Maven and GitHub Actions Minor Notes
|
| <connection>scm:git:https://github.com/bernardladenthin/java-llama.cpp.git</connection> | ||
| <developerConnection>scm:git:https://github.com/bernardladenthin/java-llama.cpp.git</developerConnection> |
There was a problem hiding this comment.
The original connection URL pointed to kherud/java-llama.cpp (upstream), while both now point to bernardladenthin/java-llama.cpp. This is a significant change:
- The
connectionURL identifies the canonical source for Maven Central metadata - CI/CD systems use this URL for builds
- Affects build reproducibility and project attribution
If this is intentional (e.g., project maintenance transferred): proceed, but document the change in commit history.
If not intentional: Consider keeping the upstream URL as the canonical source while using the personal fork for developerConnection (as it was originally configured).
| <artifactId>maven-source-plugin</artifactId> | ||
| <version>3.4.0</version> | ||
| <executions> | ||
| <execution> | ||
| <id>attach-sources</id> | ||
| <goals><goal>jar-no-fork</goal></goals> | ||
| </execution> | ||
| </executions> | ||
| </plugin> | ||
|
|
||
| <plugin> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-javadoc-plugin</artifactId> | ||
| <version>3.12.0</version> | ||
| <executions> | ||
| <execution> | ||
| <id>attach-javadocs</id> | ||
| <goals><goal>jar</goal></goals> | ||
| </execution> | ||
| </executions> | ||
| </plugin> |
There was a problem hiding this comment.
🔄 Duplicate plugin configuration
Both maven-source-plugin (v3.4.0) and maven-javadoc-plugin (v3.12.0) are already configured in the main <build> section above (lines 122-148) and will always execute. Repeating them in the release profile is unnecessary duplication.
Recommendation: Remove these duplicate plugin blocks since:
- They have identical configuration to the main build
- Source and Javadoc JARs are required for all builds, not just release builds
- Reduces maintenance burden and configuration complexity
Keep only the maven-gpg-plugin and central-publishing-maven-plugin which are release-specific.
| <configuration> | ||
| <keyname>${gpg.keyname}</keyname> | ||
| <gpgArguments> | ||
| <arg>--pinentry-mode</arg> | ||
| <arg>loopback</arg> | ||
| </gpgArguments> | ||
| </configuration> |
There was a problem hiding this comment.
📋 GPG Configuration - Missing Documentation
The GPG signing configuration references ${gpg.keyname} variable which needs to be defined for the build to work. This should be:
- Set in CI/CD environment (e.g., GitHub Actions secrets)
- Or defined in Maven settings.xml (
~/.m2/settings.xml) - Or passed via command line (
mvn -Dgpg.keyname=YOUR_KEY_ID)
Recommendation: Add a comment above this configuration block documenting where the gpg.keyname property should be defined. Also ensure your CI/CD workflow passes this value correctly during release builds.
Example CI/CD usage:
mvn deploy -P release -Dgpg.keyname=${{ secrets.GPG_KEYNAME }}
| @@ -0,0 +1,10 @@ | |||
| version: 2 | |||
There was a problem hiding this comment.
✅ Good Addition: Dependabot Configuration
This Dependabot setup is well-configured for automated dependency updates. A few notes:
- Weekly Maven updates: Will check for plugin and dependency updates
- Weekly GitHub Actions updates: Will keep your CI/CD workflows current
Optional enhancement: Consider setting open-pull-requests-limit if you want to limit concurrent PRs:
updates:
- package-ecosystem: "maven"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 5Also consider adding labels or assignees to make PRs easier to manage:
labels: ["dependencies"]
reviewers: ["bernardladenthin"]These are optional but helpful for managing many dependency updates.
| <license> | ||
| <name>MIT License</name> | ||
| <url>https://www.opensource.org/licenses/mit-license.php</url> | ||
| <distribution>repo</distribution> |
There was a problem hiding this comment.
✅ Good Addition: License Distribution Tag
Adding <distribution>repo</distribution> is correct for Maven Central requirements. This indicates the license applies to repository-hosted distributions, which is standard for open-source projects published to Maven Central.
maven-source-plugin and maven-javadoc-plugin are already configured in the main build section and run on every build. Repeating them in the release profile is redundant; the release profile now contains only the release-specific plugins: maven-gpg-plugin and central-publishing-maven-plugin. https://claude.ai/code/session_01TPLSUAgEHPFGSoDesiPZ5N
| </goals> | ||
| <goals><goal>sign</goal></goals> | ||
| <configuration> | ||
| <keyname>${gpg.keyname}</keyname> |
There was a problem hiding this comment.
Critical Issue: The pom.xml references ${gpg.keyname}, but this property is:
- Not defined as a property in pom.xml
- Not passed by the release workflow
The .github/workflows/release.yaml (line 667) runs mvn deploy without passing -Dgpg.keyname=<KEY_ID>. This will cause GPG signing to fail with "Unable to use configured keyname".
Fix: Either:
- Define
<gpg.keyname>as a property in pom.xml (not recommended for security) - Update the workflow to pass it:
mvn ... -Dgpg.keyname=YOUR_KEY_ID deploy
Note: The property should be the GPG key ID (usually the last 16 hex characters of the fingerprint)
| <version>0.10.0</version> | ||
| <extensions>true</extensions> | ||
| <configuration> | ||
| <publishingServerId>central</publishingServerId> |
There was a problem hiding this comment.
Critical Issue: The pom.xml now uses publishingServerId: central, but the release workflow (.github/workflows/release.yaml line 661) still configures the Maven server with server-id: ossrh.
The Central Publishing Maven Plugin will look for a server named central in Maven's settings.xml, not ossrh. Since the workflow sets up ossrh, the deployment will fail with authentication errors.
Fix: Update .github/workflows/release.yaml publish job:
- Change
server-id: ossrh→server-id: central(line 661) - Use Central Publisher OAuth token instead of OSSRH credentials (lines 669-670)
- Ensure ~/.m2/settings.xml has a
<server>section with idcentralcontaining the OAuth token
Reference: https://central.sonatype.org/publish/publish-maven/ for complete setup instructions
| updates: | ||
| - package-ecosystem: "maven" | ||
| directory: "/" | ||
| schedule: |
There was a problem hiding this comment.
Good addition! Weekly dependency updates for Maven dependencies and GitHub Actions.
Note: This PR's pom.xml changes require careful testing in CI. The workflow (.github/workflows/release.yaml) was not updated to match the new Central Publishing Maven Plugin configuration - there's a critical mismatch between the pom.xml and workflow that will cause release builds to fail. Be sure to coordinate the workflow updates before merging this PR or releasing.
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-javadoc-plugin</artifactId> | ||
| <version>3.5.0</version> | ||
| <version>3.12.0</version> |
There was a problem hiding this comment.
Version bump from 3.5.0 → 3.12.0 is a significant jump. This plugin was previously at 3.5.0, now 3.12.0.
Good news: This update is a stable release, not a beta. However, with such a version jump (3.5 → 3.12), ensure:
- Javadoc generation still works as expected on Java 1.8 source
- Test that
mvn package -P releasesuccessfully attaches javadoc JARs - Run a full test cycle before releasing
The corresponding update in the main build section is the same version, so at least they're consistent now.
| <license> | ||
| <name>MIT License</name> | ||
| <url>https://www.opensource.org/licenses/mit-license.php</url> | ||
| <distribution>repo</distribution> |
There was a problem hiding this comment.
Good catch - adding <distribution>repo</distribution> is required by Maven Central Repository. This was added correctly.
This setting indicates the license is available from the Maven Central repository (as opposed to manual/external distribution). It's one of the requirements for publishing to Maven Central.
| <scm> | ||
| <connection>scm:git:git://github.com/kherud/java-llama.cpp.git</connection> | ||
| <developerConnection>scm:git:ssh://github.com:bernardladenthin/java-llama.cpp.git</developerConnection> | ||
| <connection>scm:git:https://github.com/bernardladenthin/java-llama.cpp.git</connection> |
There was a problem hiding this comment.
Security improvement: SCM URLs changed from mixed protocols (git://, ssh://) to consistent HTTPS.
The original configuration used:
scm:git:git://...(unencrypted)scm:git:ssh://...(requires SSH key)
New configuration uses:
scm:git:https://...(encrypted + standard credentials)
This is more secure and compatible with Maven Central requirements. HTTPS is the recommended protocol for Maven Central artifacts.
2 participants
Summary
This PR updates the Maven build configuration to use the new Sonatype Central Repository publishing workflow, replacing the legacy OSSRH (OSS Repository Hosting) setup with the modern Central Publishing Maven Plugin.
Key Changes
nexus-staging-maven-plugin(v1.6.13) withcentral-publishing-maven-plugin(v0.9.0) for modern Central Repository publishingmaven-source-plugin(v3.3.1) to attach source JAR artifactsmaven-javadoc-plugin(v3.11.2) to attach Javadoc JAR artifactsmaven-gpg-pluginfrom v3.1.0 to v3.2.7 with enhanced configuration for GPG signing (pinentry-mode loopback support and keyname parameter)Notable Details
publishingServerId: centralinstead of the legacyossrhserver IDwaitUntil: publishedto ensure artifacts are fully published before build completionhttps://claude.ai/code/session_01TPLSUAgEHPFGSoDesiPZ5N